"Improve latency of lazy dynamic filters in some cases"? Or maybe just drop

Or "Improve latency when dynamic filtering is in use" ?

Let's drop it. It's too vague.

This is less about performance than about cost. We used to fetch 128 partitions per API call to Glue. We now fetch 1000. The query planning performance difference with and without patch was ~<5s (out of around 3m planning time, so... negligible).

This does lower cost and help avoid running into rate-limits. Not sure how that should be conveyed in release notes.

@hashhar how about

* Decrease the number of requests to the Glue metastore when fetching partitions.
  This helps avoid hitting rate limits and decreases service costs. ({issue}`4938`)

Although, not hitting a rate-limits does help performance.

reminder

is "fractional seconds" a valid term?

Yes (vs "whole seconds"). What feels weird about it?

This is out of date with the new microsecond changes. Any tables containing timestamps need to be rewritten entirely. It's actually a different PR number, since the microsecond PR would cause such tables to be completely different.

What's the suggestion? Remove it?